Stay in the meeting.
Switch the device.
From everyday friction to a seamless cross-device experience
This project started as a hackathon initiative led by my manager. I took it through to production as the sole designer — the problem was clear, the technical foundation existed, and the work was designing a solution that felt seamless across every platform. I collaborated with a desktop-focused designer on overlapping flows, and worked closely with the PM to define scope and priorities for launch.
The feature shipped covering all major platforms — desktop, web, iOS, Android, and Conference Room devices — closing a competitive parity gap with Teams and Webex.
Switching devices meant dropping out of the meeting
Dialpad Meetings users work on the move. They start a meeting walking to work or in the car, and when they reach their desk they want to continue on their laptop without losing the thread. The existing experience didn't allow for it. The problem was a known issue — the technical foundation was already there; what was missing was a solution that handled the edge cases and felt native across all platforms.
- ▪ No native transfer — the only option was to hang up on one device and rejoin on the other. Guaranteed friction, and a visible interruption for everyone in the meeting.
- ▪ Risk of duplication — if the user joined from the second device without leaving the first, they ended up connected on both simultaneously. A confusing experience for them and for other participants.
- ▪ Competitive gap — Teams and Webex already supported device switching. Dialpad didn't. For enterprise accounts, this was a real differentiator working against us.
Users away from their desk — but still in the meeting
The feature was designed for users who move through different physical contexts throughout their day. The device isn't a fixed endpoint — it's whatever is closest and most convenient at any given moment.
Three surfaces, three distinct decisions
The core challenge wasn't the flow itself — it was surfacing it consistently across four platforms with very different usage contexts. The same intent (continue this meeting on this device) needed to feel natural everywhere.
Home screen — passive detection
If there's an active meeting on another device, the home screen shows a card with the meeting name, elapsed time, and a "Switch to this device" CTA. The user doesn't have to search for anything — the app detects it automatically and surfaces the action in context.
Home screen — meeting card with switch CTA when another device is active
Join flow — intent change
When a user already in a meeting taps a Meetings link, the primary CTA shifts from "Join meeting" to "Move to this device." The option to join as a second independent participant still exists — but it's secondary, tucked under "More options" and only shown when you're already in the meeting from another device. This hierarchy was deliberate: the switch is the common case, not the double join.
.png)
Join flow — primary CTA changes to "Move to this device" when already in meeting
Desktop & web — cross-platform consistency
The same pattern was replicated on the web and desktop versions: if the meeting is active on another client, the room landing page offers the switch option. Same logic, same visual language — so the experience feels coherent regardless of where you pick it up.
Desktop — room landing with switch option when meeting is active on another client
Settings don't transfer — and that was intentional
Mic and camera use each device's own configuration. Syncing state across platforms added complexity with little real benefit — and documenting this as a deliberate decision, not a limitation, kept engineering and users aligned.
Meeting settings — device-local configuration specs
Move to This Device — interaction demo from Spring App Refresh
Engineering collaboration & design review
Throughout implementation, I worked closely with engineering to review builds and track feedback in a shared spreadsheet — flagging visual discrepancies, interaction edge cases, and platform-specific adjustments in a structured way to keep the review process clear and actionable.
Design review — structured feedback tracker shared with engineering during implementation
Shipped across all platforms — Spring App Refresh 2024
The feature launched on time across all platforms simultaneously. Post-launch data confirmed the switch works reliably when triggered — almost no errors, and consistent usage among the users who find it.
With richer participant data becoming available, the next iteration focuses on giving users more context before they even join — surfacing who's in the meeting, how long it's been running, and relevant context to help them decide when and how to switch. The goal is to make the entry point smarter, not just functional.
Next iteration — enriched participant context to add value before joining
Learnings
The device should adapt to the user's life, not interrupt it
A user can start a meeting from their car, walk into the office on their phone, and sit down at their desk — all without the other participants ever noticing. That kind of continuity isn't a feature, it's a promise: that technology doesn't get in the way of how people actually work. Designing this meant protecting the flow of work and the user's sense of presence, regardless of what device they were on.
Understand the device's constraints before designing the interaction
Every platform has different capabilities, input models, and contexts of use. The right solution isn't the same across all of them — it's the one that matches the user's need at that moment, on that device. The work was to learn those constraints first, then design in response to them — not the other way around.